On the Horizon

Worse, more complex problems such as race conditions and subtle design errors wait in the wings for the buffer overflow’s demise. Software security problems will be with us for years, and hackers will continue to exploit systems via software defects. Clearly, a central and critical aspect of the computer security problem resides in software. Software security—the idea of engineering software that continues to function correctly under malicious attack—is not new, but it is receiving renewed interest as reactive network-based security approaches such as firewalls prove to be ineffective. Unfortunately, today’s software is riddled with both design flaws and implementation bugs, which result in unacceptable security risks. As security researcher Steve Bellovin puts it, “any program, no matter how innocuous it seems, can harbor security holes.” This notion is common knowledge, and yet developers, architects, and computer scientists only recently began systematically to study how to build secure software. In fact, the first books on software security and security engineering were published in 2001,2–4 and a body of literature on the subject has just begun to emerge. (See Further reading sidebar.) The DIMACS Software Security Workshop held in New Jersey this January (http://dimacs.rutgers.edu/ Workshops/Software) explored issues such as security engineering, architecture and implementation risks, security analysis, mobile and malicious code, education and training, and open research issues. Many promising techniques have grown from connections between computer security, programming languages, and software engineering, and one workshop goal was to bring these communities closer together to crystallize the software security subfield. I report the workshop’s results in this article.